Managing Technical Debt

1.3.1.1. The Promise of Managing Technical Debt

1.3.1.2. Technical Debt A-B-C

1.3.1.3. Examples of Technical Debt

1.3.1.4. Your Own Story About Technical Debt?

1.3.1.5. Who Is This Book For?

1.3.1.6. Principles of Technical Debt Management

1.3.1.7. Navigating the Concepts of the Book

1.3.1.8. What Can You Do Today?

1.3.1.9. For Further Reading

1.3.2.1. Mapping the Territory

1.3.2.2. The Technical Debt Landscape

1.3.2.3. Technical Debt Items: Artifacts, Causes, and Consequences

1.3.2.4. Principal and Interest

1.3.2.5. Cost and Value

1.3.2.6. Potential Debt versus Actual Debt

1.3.2.7. The Technical Debt Timeline

1.3.2.8. What Can You Do Today?

1.3.2.9. For Further Reading

1.3.3.1. ``It Depends…’’

1.3.3.2. Three Case Studies: Moons of Saturn

1.3.3.3. Technical Debt in Context

1.3.3.4. What Can You Do Today?

1.3.3.5. For Further Reading

1.4.1.1. Where Does It Hurt?

1.4.1.2. What Are the Visible Consequences of Technical Debt?

1.4.1.3. Writing a Technical Debt Description

1.4.1.4. Understanding the Business Context for Assessing Technical Debt

1.4.1.5. Assessing Artifacts Across the Technical Debt Landscape

1.4.1.6. What Can You Do Today?

1.4.1.7. For Further Reading

1.4.2.1. Looking for the Magic Wand

1.4.2.2. Understand Key Business Goals

1.4.2.3. Identify Questions About the Source Code

1.4.2.4. Define the Observable Measurement Criteria

1.4.2.5. Select and Apply an Analysis Tool

1.4.2.6. Document the Technical Debt Items

1.4.2.7. Then Iterate

1.4.2.8. What Happens Next?

1.4.2.9. What Can You Do Today?

1.4.2.10. For Further Reading

1.4.3.1. Beyond the Code

1.4.3.2. Ask the Designers

1.4.3.3. Examine the Architecture

1.4.3.4. Examine the Code to Get Insight into the Architecture

1.4.3.5. The Case of Technical Debt in the Architecture of Phoebe

1.4.3.6. What Can You Do Today?

1.4.3.7. For Further Reading

1.4.4.1. Beyond the Architecture, the Design, and the Code

1.4.4.2. Build and Integration Debt

1.4.4.3. Testing Debt

1.4.4.4. Infrastructure Debt

1.4.4.5. The Case of Technical Debt in the Production of Phoebe

1.4.4.6. What Can You Do Today?

1.4.4.7. For Further Reading

1.5.1.1. Shining an Economic Spotlight on Technical Debt

1.5.1.2. Refine the Technical Debt Description

1.5.1.3. Calculate the Cost of Remediation

1.5.1.4. Calculate the Recurring Interest

1.5.1.5. Compare Cost and Benefit

1.5.1.6. Manage Technical Debt Items Collectively

1.5.1.7. What Can You Do Today?

1.5.1.8. For Further Reading

1.5.2.1. Weighing the Costs and Benefits

1.5.2.2. Risk Exposure

1.5.2.3. Opportunity Cost

1.5.2.4. Paths for Servicing Technical Debt

1.5.2.5. The Release Pipeline

1.5.2.6. The Business Case for Technical Debt as an Investment

1.5.2.7. What Can You Do Today?

1.5.2.8. For Further Reading

1.6.1.1. The Perplexing Art of Identifying What Causes Debt

1. Managing TD is an ongoing, integral part of the software development lifecycle.
   
   • It feels good to get it out of your system, but as you talk about it, the debt keeps building.
     
   • Understand the realities and complexities of software development that cause the debt.
     
   1. All systems have technical debt
      
   2. Technical debt mus trace to the system
      

1.6.1.2. The Roots of Technical Debt

1.6.1.3. What Causes Technical Debt?

1.6.1.4. Causes Rooted in the Business

1. Time and Cost Pressure
   
   • Customers care only about introduce new functionality rapidly, giving almost no thought to what functionalities the users will need in the future (short-sighted and completely focused on tactical, immediate needs)
     
   • Instead of taking the time to do things right, we keep adding things all over the system
     
2. Misalignment of Business Goals
   

   Lack of clear business goals will lead to TD when the designed system does not match the expectations of the customers
   

3. Requirements Shortfall
   
   • Not articulating detailed requirements, not implementing expected functionality,
     

   and not understanding architecturally significant, cross-cutting requirements such as security,
   performance, and availability will all cause technical debt.
   

   • Developers often react to ambiguous and poorly understood requirements by either making narrow choices for the limited requirements they do understand or making overly general choices in the hope of anticipating the eventual requirements. Both responses add complexity
     

1.6.1.5. Causes Arising from Change in Context

1.6.1.6. Causes Associated with the Development Process

1. Ineffective Documentation
   
   • architectural design and test documentation
     
   • The documentation must be effective: accessible, pertinent, and up to date, otherwise TD occurs
     
   • feedback loop: under pressure, some developers won’t document, which makes less likely other developers will document later on
     
   • Without effective documentation, the process of bringing in the new team members becomes longer and more error prone
     
   • There is a limit to “the code is the documentation”, e.g. design/architectural decisions such as using X library instead of Y (not explicit in any part of the code)
     
2. Insufficient Testing Automation
   
   • Development teams focus on testing what they develop for the current release and not what they developed for previous releases => they introduce inconsistencies throughout the system that cause rework in the codebase, build scripts, and test suites.
     
   • Developers are concerned that refactoring may adversely affect the system’s behavior and introduce undetected defects => they may prefer to live with not-quite-right code that does the job rather than improve the internal structure of the code at the risk of altering its behavior.
     
3. Misalignment of Processes
   

1.6.1.7. Causes Arising from People and Team

1. Inexperienced Teams
   

   symptoms -> it takes you forever to finish even a simple task, functions are inefficient/nedlessly complex, copy paste and code smells
   

   • Provide the right learning environment to succeed
     
   • Design hiring and training procedures
     
   • Focused analysis tools to identify, prioritize, fix the issues
     
   • Inexperienced managers cause either delays to the dev team explaining what they are doing, or by managing at a high level of abstraction, delays by putting management task on the shoulders of developers
     

   While lack of experience can inject unintentional technical debt into a system, getting caught up in the blame game will take the product or the team nowhere.
   

2. Distributed Teams
   
3. Undedicated Teams
   

   This creates:
   

   1. Task switching
      
   2. Priority shifts
      

1.6.1.8. To Conclude

1.6.1.9. What Can You Do Today?

1.6.1.10. For Further Reading

1.6.2.1. Identifying Causes: Technical Debt Credit Check

1.6.2.2. Four Focus Areas for Understanding the State of a Project

1.6.2.3. Diagnosing the Causes of Technical Debt in Phoebe

1.6.2.4. Diagnosing the Causes of Technical Debt in Tethys

1.6.2.5. What Can You Do Today?

1.6.2.6. For Further Reading

1.6.3.1. Software Engineering in a Nutshell

1.6.3.2. Code Quality and Unintentional Technical Debt

1.6.3.3. Architecture, Production, and Unintentional Technical Debt

1.6.3.4. What Can You Do Today?

1.6.3.5. For Further Reading

1.6.4.1. Your Technical Debt Toolbox

1.6.4.2. On the Three Moons of Saturn …

1.6.4.3. Technical Debt and Software Development

1.6.4.4. Finale

1.6.7.1. A

1.6.7.2. B

1.6.7.3. C

1.6.7.4. D

1.6.7.5. E

1.6.7.6. F

1.6.7.7. G

1.6.7.8. H

1.6.7.9. I

1.6.7.10. J-K

1.6.7.11. L

1.6.7.12. M

1.6.7.13. N

1.6.7.14. O

1.6.7.15. P

1.6.7.16. Q

1.6.7.17. R

1.6.7.18. S

1.6.7.19. T

1.6.7.20. U

1.6.7.21. V

1.6.7.22. W

1.6.7.23. X-Y-Z